Bug: Underlying() causes false positives for named types based on int

The comment on line 71 says "exact type int", but argType.Underlying() also matches any named type whose underlying type is int, e.g.:

type Status int
var s Status = 5
fmt.Sprintf("%d", s) // ← flagged by this linter

The suggested fix strconv.Itoa(s) fails to compile because strconv.Itoa only accepts int, not Status. Use exact type equality instead:

if argType != types.Typ[types.Int] {
    return
}

This limits the linter to the exact predeclared int type and avoids broken auto-fix suggestions for named int types.

@copilot please address this.

Minor: analyzer registration is out of alphabetical order

The imports (lines 47–49) are correctly sorted: sprintferrdot → sprintferrorsnew → sprintfint. But the registration in main() has sprintfint.Analyzer inserted before sprintferrorsnew.Analyzer, which reverses the correct order (sprintferr... < sprintfi... lexicographically).

Expected order:

sprintferrdot.Analyzer,
sprintferrorsnew.Analyzer,
sprintfint.Analyzer,

@copilot please address this.

Missing test case: named type based on int

After fixing the Underlying() type check, add a test fixture that confirms named int types are not flagged:

// goodNamedInt uses a named type based on int — not flagged, because
// strconv.Itoa does not accept named types.
func goodNamedInt(n Counter) string {
    type Counter int  // or defined at package level
    return fmt.Sprintf("%d", n)
}

Without this, a future refactor that reintroduces Underlying() could silently re-break the behaviour.

@copilot please address this.

Underlying() match fires on named int types but generates uncompilable SuggestedFix: type MyInt int; fmt.Sprintf("%d", myIntVar) passes this guard (because MyInt.Underlying() == types.Typ[types.Int]), but the emitted fix strconv.Itoa(myIntVar) does not compile—strconv.Itoa only accepts bare int, not a named type.

// Before — incorrectly matches named types derived from int
if argType.Underlying() != types.Typ[types.Int] {
    return
}

// After — only matches the exact built-in int type
if argType != types.Typ[types.Int] {
    return
}

SuggestedFix omits the strconv import, producing uncompilable code when applied in files that don't already import it: the TextEdit only rewrites the call site. Any file where "strconv" is not yet imported will fail to compile after the fix is applied.

sprintfint.Analyzer is registered out of alphabetical order: it appears between sprintferrdot and sprintferrorsnew, but alphabetically sprintferr* < sprintfint (since 'e' < 'i'). The import block in this same file is in the correct order (sprintferrorsnew → sprintfint → ssljson); the main() slice should match.

// in main()
sprintferrdot.Analyzer,
sprintferrorsnew.Analyzer,  // move before sprintfint
sprintfint.Analyzer,

Missing test case for named int types: the fixture has no case like type MyInt int; fmt.Sprintf("%d", myIntVar), which is the exact scenario where the Underlying()-based type check produces a false positive and the generated SuggestedFix emits uncompilable code. Add a // want -free case (or an explicit no-diagnostic marker) to catch regressions on this boundary once the type check is corrected.

type myInt int

// goodNamedInt is a named type; the linter must NOT flag this because the
// suggested fix strconv.Itoa(x) would not compile for a non-int type.
func goodNamedInt(n myInt) string {
    return fmt.Sprintf("%d", n) // no diagnostic expected
}